A. Field of the Invention
The present invention is related to a method for delivering a public network address of a secondary address server to a dial-up remote access client. In particular, the invention relates to a method for using Internet Protocol Control Protocol to assign public Internet protocol addresses from a secondary address server to a Realm Specific Internet Protocol (RSIP) aware remote access client having a private IP address.
B. Description of the Related Art
As the Internet has experienced explosive growth in recent years, the number of unallocated unique public IP addresses has dwindled. This lack of addresses poses a problem for networks that have only private IP addresses that are unusable outside the network, e.g. companies using an intranet that requires that the internal addresses be kept private. If such a user desires Internet connectivity, the user must either renumber his devices or find a way to use existing public addresses. One approach to solving this problem is to use Network Address Translation (NAT) when connecting to the Internet. See P. Srisureh, “IP Network Address Translator (NAT) Terminology and Considerations,” IETF RFC 2663, August 1999, which is incorporated herein by reference.
NAT provides a method for transparent bi-directional communication between a private routing realm, for example a private intranet, and an external routing realm, for example, the Internet. Through use of NAT, addresses of packets sent by the first realm are translated into addresses associated with the second realm. Use of private IP addresses in conjunction with an NAT implementation in the router card for an ISP would therefore allow the ISP to conserve globally-routable public IP addresses.
The use of private IP addresses in conjunction with an NAT, however, presents problems in several applications. In applications that transmit IP addresses in packet payloads, NAT requires an application layer gateway to function properly. Problems with NAT support for end-to-end protocols, especially those that authenticate or encrypt portions of data packets, are also particularly well-known. See, e.g., Holdrege et al., “Protocol Complications with the IP Network Address Translator,” Internet Draft <draft-ietf-nat-protocol-complications-01>, June 1999. NAT also creates difficulties when applied to Internet security applications.
As an alternative, RSIP has been proposed at a replacement for NAT. See M. Borella. et al., “Realm Specific IP: Protocol Specification,” Internet Draft <draft-ietf-nat-rsip-protocol-07>, July 2000, which is incorporated herein by reference. Using RSIP, a client and server (e.g., a dialup client and an RSIP server, which may be part of a router card or a standalone device) negotiate the use of a public IP address and possibly some number of Transmission Control Protocol (TCP)/User Datagram Protocol (UDP) ports. After enabling RSIP in the ISP and on clients, the RSIP-aware clients can share one or more IP addresses instead of each requiring a dedicated address.
RSIP requires that an application on the client communicate with an application on the RSIP server, so the communication link must be configured for IP before this communication occurs. The RSIP client must also know the IP address of the RSIP server, so that it can contact the server directly. Thus, there is a need in the art for a method by which an RSIP client can determine the IP address of an RSIP server. There is also a need in the art for a process by which a dial-up client and a set of ISP equipment may use RSIP to assign IP addresses from the ISP equipment to the dial-up client in order to conserve globally-routable IP addresses.